You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Exports need their stack pointer and thread-local storage set up. For this, in wasip3, wasi-libc can export __wasilibc_init_task(_async) functions that should be called before the real component exports are called. This PR introduces a new module into components generated by wit-component when it detects __wasilibc_init_task(_async) functions exported from the main module.
This new module is called wasilibc-init-wrappers. For every function the component exports, it imports that function, and exports a wrapper that calls the relevant task initialization function before calling the original export. I did this with a separate module to cleanly separate out the logic, but could dump the wrappers into the original module or the shim if desired.
With non-wasi-libc languages (e.g. Go) I think we'll rpobably want to drop the wasilibc part of the symbol names here, but having __init_task and __init_async_task (or something like that) seems reasonable to me.
Long-term I think we'll want to avoid the need to create an extra module here. That has code size and inlining implications in wasm runtimes and this will, by default, affect all exports for WASIp3+ components. Given that impact I think eventually we'll want to inject these wrappers in the original module rather than in an auxiliary module. In the meantime, however, that's a fair bit of infrastructure not already in wit-component so I don't want to put that on you here. Instead wanted to confirm you feel this is a reasonable path (eventually) and then we can file an issue about it.
For testing this you can add a component/core module to crates/wit-component/tests/components and that has various WIT/WAT/etc files to combine to ensure this has at least smoke tests for the produced module.
I think we'll probably want to drop the wasilibc part of the symbol names here
Sure, maybe worth keeping a wasm prefix or something? And I think ideally, when we have the design for all of this stuff more fully fleshed out, I'd like to have all of these symbols documented as part of the BuildTargets or some general toolchain ABI document.
Long-term I think we'll want to avoid the need to create an extra module here
Yeah, that sounds good to me.
For testing this you can add a component/core module to crates/wit-component/tests/components and that has various WIT/WAT/etc files to combine to ensure this has at least smoke tests for the produced module.
On one hand that seems redundant to have a wasm prefix (everything is wasm after all) but on the other hand it doesn't hurt to be explicit. Basically I could go either way myself, happy to defer to your judgement
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Exports need their stack pointer and thread-local storage set up. For this, in wasip3,
wasi-libccan export__wasilibc_init_task(_async)functions that should be called before the real component exports are called. This PR introduces a new module into components generated bywit-componentwhen it detects__wasilibc_init_task(_async)functions exported from the main module.This new module is called
wasilibc-init-wrappers. For every function the component exports, it imports that function, and exports a wrapper that calls the relevant task initialization function before calling the original export. I did this with a separate module to cleanly separate out the logic, but could dump the wrappers into the original module or the shim if desired.